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I.  INTRODUCTION 

The  Army  Materiel  Command  (AMC)  Research,  Development,  and  Engineering  Center 
(RDEC)  Federation  (referred  to  as  the  Federation  henceforth)  is  a  distributed  engineering  and 
engagement  level  modeling  and  simulation  environment.  The  Federation  is  a  persistent  High 
Level  Architecture  (HLA)-based  collaboration  of  US  Army  RDECs,  Army  Research  Lab  (ARL), 
and  Simulation,  Training,  and  Instrumentation  Command  (STRICOM).  These  participants 
include  the  Aviation  and  Missile  Command’s  (AMCOM)  aviation  and  missile  simulations  and 
data  collection  tools;  the  Tank,  Automotive,  Research,  Development  and  Engineering  Center 
(TARDEC)  ground  vehicle  and  armament  simulation;  the  Communications  and  Electronics 
Command’s  (CECOM)  Command,  Control,  Communication,  Computers  &  Intelligence, 
Surveillance,  Reconnaissance  (C4ISR)  sensor  simulations;  the  ARL  vulnerability/lethality 
assessment  models,  human  engineering  models,  HLA  utilities,  and  Dismounted  Infantry 
STRICOM  simulation  support  technologies  such  as  the  Computer  Generated  Forces  model 
OneSAF  Testbed.  The  collection  of  federates  participating  in  any  individual  event  of  the 
Federation  is  based  upon  customer  needs  and  technical  objectives  with  capability  to  extend  and 
interoperate  with  battle  and  campaign  level  models  and  simulations. 

The  usable  product  of  the  Federation  is  a  distributed,  collaborative,  composable  modeling 
and  simulation  environment  with  robust  Model  and  Simulation  (M&S)  capabilities  and  an 
architecture  sufficient  to  support  analysis  of  the  Objective  Force.  The  initial  objective  of  the 
Federation  is  to  develop  an  HLA  compliant  test  bed  to  support  Future  Combat  Systems  (FCS) 
analysis  and  experimentation.  Key  efforts  include  the  linking  of  each  RDEC/Laboratory’s 
engineering  level  models  and  establishing  a  federated  data  collection/analysis  capability  so  that 
an  integrated  distributed  collaborative  M&S  environment  is  established  which  is  capable  of 
supporting  system-of-system  and  cross-functional  area  tradeoffs  and  assessments. 

The  first  integration  of  the  Federation  was  demonstrated  at  the  SMART  Conference  in 
April  2001,  in  Orlando,  Florida.  During  this  conference,  all  Federation  players  came  together 
and  successfully  demonstrated  the  integration  between  sites  and  did  some  preliminary  analysis 
using  data  collection  tools.  However,  the  vision  of  the  Federation  was  for  all  players  to  be  able 
to  play  distributed  from  their  own  facilities.  During  the  second  test  of  the  Federation  called  the 
Calibration  Experiment  (CalEx),  which  this  report  discusses,  the  goal  was  to  successfully 
demonstrate  the  capability  of  the  Federation  to  operate  in  a  distributed  environment  over  a  Wide 
Area  Network  (WAN)  and  expand  upon  the  capabilities  of  the  Federation  demonstrated  at 
SMART.  Another  major  goal  was  to  be  able  to  conduct  data  analysis  on  the  results  obtained. 

During  the  SMART  conference,  two  separate  networks  were  maintained  for  DIS  and 
HLA  traffic.  For  the  CalEx,  HLA  was  the  primary  communication  mechanism  and  DIS  systems 
were  connected  to  the  network  via  multiple  Mak  Gateways.  This  report  will  discuss  the  network 
architecture  of  the  CalEx  and  the  challenges  encountered  during  the  integration  and  testing  of  the 
experiment  using  the  Defense  Research  and  Engineering  Network  (DREN).  The  report  will 
discuss  the  Local  Area  Network  (LAN),  Metropolitan  Area  Network  (MAN),  and  WAN 
challenges  encountered  during  CalEx,  how  these  challenges  were  dealt  with,  and  also  present 
some  recommendations  for  moving  forward  and  conducting  future  HLA  experiments  using  the 
DREN. 
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II.  CalEx  SIMULATION  EXPERIMENT 


To  understand  the  complexities  presented  by  CalEx,  an  overview  of  the  simulation, 
system,  and  network  architecture  will  be  discussed  as  well  as  the  test  procedure  methodology 
that  was  employed. 

A.  Simulation  Architecture 

The  simulation  architectural  backbone  of  CalEx  was  HLA.  Appending  that 
backbone  at  the  appropriate  LAN  level  was  tactical  C4ISR  and  DIS  networks  to  support  RDEC 
federates  utilizing  those  protocols.  The  tactical  C4ISR  network  interfaces  are  compatible  with 
the  evolving  Army  Tactical  Command  and  Control  System  (ATCCS)  standards  and  versions, 
and  will  stimulate  tactical  C4ISR  equipment.  In  addition,  there  were  some  custom  C4ISR 
interfaces  to  Research  and  Development  (R&D)  devices  used  to  explore  future  C4ISR  concepts, 
as  defined  by  CECOM. 

The  RDEC  Federation  backbone  currently  utilizes  the  DMSO  Run-Time 
Infrastructure  (RTI)  1.3NG  v3.2.  The  primary  RDEC  Federation  Object  Model  (FOM)  is  a 
superset  of  the  Real-Time,  Platform  Reference  (RPR)  FOM  version  1.0,  with  extensions  to  allow 
exchange  of  server  data  and  target  acquisition  data.  The  Federation  is  following  the  “Guidance, 
Rationale,  and  Interoperability  Modalities”  (GRIM)  guidelines  for  enumerations  and 
implementation  of  RPR-FOM  where  possible.  The  servers  currently  supported  are  the  Missile 
Server  (AMCOM),  Active-Protection  System  (APS)  Server  (AMCOM),  Mobility  Server 
(TARDEC),  and  the  Vulnerability  Server  (ARL). 

In  addition  to  the  primary  FOM  being  implemented  for  CalEx,  the  Federation 
supports  the  use  of  multiple  FOMs  with  bridges.  A  bridge  was  used  to  link  the  RPR-based 
primary  FOM  with  the  Paint-The-Night  and  SWISS  Together!  (PST)  FOM.  The  PST  FOM 
consists  of  interactions  allowing  distributed  control  of  sensor  views  from  controls  and  switches 
in  remote  locations.  The  PST  architecture  also  uses  External  Data  Representation  (XDR),  which 
is  not  supported  by  the  primary  architecture.  The  lack  of  XDR  support  did  introduce  some 
integration  hurdles. 

The  Federation  DIS  network  currently  operates  in  accordance  to  DIS  Version 
2.04.  Some  non-standard  PDU  traffic  is  also  allowed  on  a  case-by-case  basis  to  allow  DIS 
simulations  to  call  and  receive  server  information.  The  DIS  traffic  is  connected  to  the  HLA 
backbone  through  an  HLA  gateway.  The  gateway  used  was  MAK’s  Gateway  version  3.4,  which 
is  compatible  with  RPR  FOM  1.0  and  is  designed  to  ignore  extension  data  to  that  FOM  without 
dysfunction. 


2 


B.  Systems  and  Network  Architecture 

The  Federation  integrates  several  federates  from  each  of  the  participating  RDEC 
sites.  The  integration  of  all  these  simulation  systems  at  these  sites  provides  a  comprehensive, 
robust  representation  of  the  modem  Army  warfighting  environment.  This  includes  system 
representations  ranging  from  Sensor  and  Target  Acquisition  Systems,  C4ISR,  and  multi-purpose 
Computer  Generated  Force  (CGF)  simulations.  Also,  system  performance  and  effects  servers 
modeling  physical  effects  such  as  mobility  and  lethality  were  incorporated  to  accurately  portray 
these  effects  over  the  generic  representations  available  in  CGFs.  Finally,  the  data  produced  by 
these  systems  was  captured  and  analyzed  by  specialized  logging  and  analysis  applications 
focused  on  capturing  the  results  pertinent  to  the  Federation  requirements.  Figure  1  provides  an 
overview  of  the  simulations  used  in  CalEx.  Some  of  the  major  components  are  described  as 
follows: 


1 .  The  following  is  the  list  of  platform  simulations  used  for  CalEx: 

a.  OneSAF  Test  Bed  (OTB).  OTB  is  the  primary  platform  level 
simulation  used  in  the  federation,  representing  all  the  red  platforms  and  many  of  the  blue  ground 
forces. 
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b.  Interactive  Tactical  Environment  Management  System 
(ITEMS).  ITEMS  is  a  commercial  platform  level  simulation  used  by  AMRDEC  to  represent 
rotary-wing  assets.  ITEMS  provided  the  primary  aviation  models  used  during  the  CalEx  scenario 
runs,  representing  the  attack  Rotary  Winged  Aircraft  (RWA),  (Apache  AH64D)  systems,  as  well 
as  two  A- 160  Unmanned  Aerial  Vehicle  (UAV)  systems.  ITEMS  Version  6.0  is  DIS  compliant, 
and  an  RPR-FOM  based  HLA  version  is  under  development. 

2.  The  following  is  the  list  of  virtual  prototypes  used  for  CalEx: 

a.  VETRONICS  Technology  Testbed  (VTT).  The  Embedded 
Simulation  (ES)  VTT  is  a  crewstation  architectural  design  that  was  provided  to  the  FCS 
Consortiums.  The  ES  system  allows  for  the  functional  simulation  interface  with  the  crewstation 
controls  to  perform  such  mission  functions  as  embedded  training,  mission  rehearsal,  operational 
enhancements,  and  virtual  Test  and  Evaluation. 

b.  Robotics  Controllers.  The  Robotic  Operator  Control  Unit  (OCU) 
provides  interactive  representation  of  the  mission  planning  functionality  for  the  RSTA  sensor 
robotic  scout  vehicle,  modeled  by  the  VDM  mobility  server  (below). 

3.  The  following  is  the  list  of  C4ISR  simulations  used  for  CalEx: 

a.  Communications.  The  RDEC  Federation  includes  CERDEC’s 
Tactical  Internet  Model  and  Next  Generation  Performance  Model  (NGPM)  to  provide  noise  and 
message  dropouts  to  simulate  realistic  digital  communications  and  the  appropriate  degradation  of 
Global  Positioning  System  (GPS)  and  SA  performance 

b.  Command  and  Control.  The  Commander’s  Interactive  Display 
(CID)  is  a  CERDEC  research  testbed  for  future  command  and  control  functions  and  displays. 

The  CID  displays  tactical  information  fused  from  simulated  sensor  and  reconnaissance  sources 
to  provide  the  warfighter-in-the-loop  with  advanced  situational  awareness,  and  provides  decision 
support  tools  to  support  execution  of  commands  in  coordination  with  Battle  Planning  and 
Visualization  tools.  CERDEC  also  provides  FBCB2  stimulation  tools. 

c.  Sensor  Suites.  Paint  The  Night  (PTN)  is  a  CERDEC  Night  Vision 
and  Electronic  Sensors  Directorate  (NVESD)  high  fidelity  Electrooptical/Infrared  (EO/IR) 
virtual  imaging  simulation  which  can  drive  remote  displays  in  response  to  remote  control  inputs, 
allowing  it  to  provide  sensor  views  to  virtual  prototypes  such  as  VTT  on-board  Target 
Acquisition  Sensor,  Unmanned  Ground  Vehicle  (UGV)  imaging  sensors,  and  Infrared  (IR) 
Unmanned  Ground  System  (UGS)  sensors. 

The  CERDEC  NVESD  also  provides  Generic  Entity  Controller 
(GEC),  a  common  control  capability  to  represent  and  allow  operator  interaction  with  multiple 
entities  such  as  UGS  Imaging  (cameras)  and  Non-Imaging  sensors  (Seismic/ Acoustic/Magnetic), 
command-activated  mines  and  non-lethal  munitions. 
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The  CERDEC  NVESD  also  provides  the  Comprehensive  Mine 
Simulation  (CMS),  which  produces  mine  fields  using  the  Compact  Terrain  Database  (CTD). 


4.  The  following  is  the  fire  support  simulation  used  for  CalEx: 

Fire  Support.  ARDEC  provides  a  Future  Fires  Decision  Support 
System  (F2DSS)  which  receives  tactical  target  report  messages  and  calls  for  fire,  provides 
decision  support  to  a  man-in-the-loop  operator,  and  sends  out  the  appropriate  simulation  network 
calls  to  missile  and  munitions  servers. 

5.  Simulation  Servers 

a.  Vulnerability  Server:  ARL  contributed  the 
Vulnerability/Lethality  server,  which  provides  a  monitor  and  tracking  capability  of  damage  state 
changes  on  the  federation. 

b.  Mobility  Server:  The  Vehicle  Dynamics  and  Mobility  Server 
(VDMS)  is  a  complete,  interactive  ground  vehicle  platform  model  that  executes  on  the  TACOM- 
TARDEC  High  Performance  Computing  (HPC)  Distributed  Center  assets  and  communicates 
over  a  network  with  other  entities  in  a  larger  distributed  simulation.  The  VDMS  ground  platform 
provides  a  high  fidelity  model  of  vehicle  subsystems,  including  powertrain,  suspension,  steering, 
etc. 


c.  Missile  Server:  AMRDEC  has  developed  the  missile  server  as 
an  outgrowth  of  the  Interactive  Distributed  Engineering  Evaluation  and  Analysis  Simulation 
(IDEEAS)  simulation.  The  missile  server  receives  fire  requests  from  tactical  or  simulated 
entities  and  instantiates  missiles  in  flight  using  high  fidelity  kinematics  and  seeker  models,  and 
detonates  missile  warheads  in  accordance  with  accurate  fusing. 

For  a  more  in  depth  view  of  CalEx  from  a  simulation  “Lessons  Learned”  perspective  see 
Reference  1. 
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III.  NETWORK  PERFORMANCE  OBSERVATIONS 


A.  Network  Architecture 

Figure  2  provides  an  overview  of  the  network  used  during  CalEx.  Basically, 
there  are  three  components,  as  previously  mentioned,  the  LAN,  the  MAN,  and  the  WAN.  The 
LAN  is  defined  as  all  of  the  machines  and  network  devices  that  supported  or  were  dedicated  to 
each  site  operation.  The  MAN  is  defined  as  the  networking  devices  that  supported  the  base  or 
installation,  and  through  which  each  site  had  to  traverse  to  reach  the  DREN.  The  WAN  is 
defined  as  the  long-haul  networking  devices  which  each  base  or  installation  traversed  to  reach  all 
other  bases  and  installations. 


Figure  2.  CalEx  Network  Architecture 

The  LAN  was  supported  at  most  sites  by  Ethemet(802.3)  technology.  For  CalEx, 
each  site  was  requested  to  be  in  switched,  full  duplex  mode  to  minimize  any  collision  overhead. 
For  readers  interested  in  more  information,  visit  http://www.rware.demon.co.uk/ethemet.htm. 
The  Ft.  Belvoir  site  was  unique  in  that  it  used  mostly  Asynchronous  Transfer  Modulation  (ATM) 
technology.  ATM  is  a  switched  technology,  which  provides  Quality  of  Service  (QoS)  and  is 
capable  of  extending  through  the  WAN/MAN/LAN  environment.  For  more  information  on 
ATM  technology,  visit  http://www.atmfomm.com. 
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B.  Network  Tools 

A  number  of  network  tools  were  used  to  monitor  the  health  and  status  of  the 
network  on  a  daily  basis.  To  determine  the  status  of  multicast,  the  mtrace,  mrinfo,  and  sdr 
utilities  were  used.  Mtrace  provided  the  most  useful  information  on  how  the  path  along  the  IP 
multicast  tunnel  was  configured.  It  was  optimal  to  run  mtrace  from  both  directions  to  ensure 
each  path  was  symmetric.  Problems  that  could  be  identified  using  mtrace  included  network 
configuration  changes  that  resulted  in  asymmetric  routing  or  routes  that  did  not  properly  run  over 
the  DREN.  Both  of  these  problems  resulted  in  large  latencies  or  lack  of  connectability  of  the 
federates  over  the  DREN.  Another  tool  that  was  quite  useful  isolating  problems  was  mrinfo. 
Mrinfo  returned  the  status  of  the  tunnel  endpoints.  The  sdr  utility,  though  not  a  performance  tool, 
was  also  run  and  was  used  as  an  indicator  of  the  stability  of  the  multicast  tunnels.  To  test  the 
health  and  status  of  TCP/IP,  the  ping  and  traceroute  utilities  were  used.  Also,  to  check  for 
overall  bandwidth,  SGI's  Netvisualizer  and  Fluke  lanmeters  were  used. 

C.  Requirements 

The  RDEC  Federation  required  that  all  participants  integrate  using  a  direct 
connection  over  the  DREN.  The  STRICOM  Orlando  site  connected  initially  via  the  Internet; 
however,  they  were  successful  in  connecting  to  the  DREN  approximately  a  month  before  the 
“Runs  for  Record.”  A  star  configuration  for  IP  multicast  tunnels  was  implemented  and  ARL 
served  as  the  central  connection  site.  Each  multicast  tunnel  was  set  to  default  configuration, 
which  included  a  10-mbits/sec  allotment. 

The  requirement  for  the  DREN  was  to  ensure  each  site  had  sufficient  bandwidth 
with  minimal  latency.  A  latency  of  no  more  than  50msec  round  trip  was  required.  Sites 
connected  on  using  FORE  ATM  equipment  included:  ARL,  CECOM-NVL,  TARDEC,  ARDEC, 
and  AMCOM.  Sites  connected  on  the  DREN  using  Cisco  Border  routers  included:  CECOM- 
12 WD  and  initially  STRICOM.  Each  site  connection  had  a  minimum  of  45mbits/sec  bandwidth 
with  some  fraction  available  to  the  RDECs. 

D.  Problems  Encountered 

There  were  many  network  problems  encountered.  Some  of  the  more  significant 
ones  were  as  follows: 

1 .  The  tunnel  endpoint  systems  were  overwhelmed  by  the  traffic  produced 
by  the  CalEx  network  traffic.  In  discussions  with  DREN  personnel,  it  appeared  that  the  CalEx 
effort  was  one  of  the  largest  exercises  that  used  the  DREN,  both  in  the  number  of  sites  connected 
and  the  amount  of  traffic  generated. 

2.  The  initial  Multicast  tunnel  configurations  were  insufficient  to  handle 
network  traffic  generated  during  CalEx. 

3  Fedex  and  rtiexec  processes  run  on  underpowered  systems  or  from  sites 
with  insufficient  bandwidth  introduced  latency  or  connectability  problems. 
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4.  Each  site  was  required  to  interface  using  the  HLA  RTI  1.3NG  v3.2  and  the 
RPR  FOM.  Some  sites  used  native  HLA  in  connecting  to  the  federation  while  others  used  the 
Mak  Gateway  to  translate  DIS  to  HLA.  During  integration  for  CalEx,  the  Federation 
experimented  with  using  reliable  (tcp/ip)  versus  best  effort  (multicast)  transport  mechanisms. 
While  reliable  guaranteed  delivery  of  packets,  its  usage  also  introduced  a  severe  load  on  the 
network  due  to  acks  and  retransmits.  On  occasion,  the  reliable  traffic  was  introducing  2 
mbytes/sec  (~16mbits/sec)  network  storms,  which  caused  large  latencies  in  the  simulation.  Early 
attempts  to  run  in  best  effort  mode  resulted  in  large  packet  losses. 

5.  Sites  changed  firewall  settings  quite  often  over  the  course  of  CalEx.  Most 
of  this  was  as  a  result  of  the  events  of  1 1  September  2001,  and  the  subsequent  security  alerts. 
Sites  that  on  one  day  had  superb  connections,  on  the  next  day  could  neither  be  seen  nor  heard  by 
a  number  of  the  participating  sites. 

6.  Probably  the  most  frustrating  problem  encountered  was  network  stability. 
A  large  amount  of  resources  were  dedicated  to  sites  that  had  connectivity  problems  other  than 
those  discussed  above.  These  usually  were  tied  to  configuration  of  the  routers/switches  at  each 
site.  Many  times,  once  a  site  was  debugged  it  was  fairly  operational  for  a  few  days.  However, 
there  were  many  changes  (routing  and  access  control  list  modifications)  made  at  the  MAN  level. 
They  were  numerous,  and  during  this  time  period,  usually  were  made  in  efforts  to  enhance 
security  due  to  the  tragedy  of  1 1  September  2001.  These  changes  were  usually  not  coordinated 
with  the  administrators  at  the  LAN  or  WAN  level,  and  the  result  was  a  very  unstable  and 
inoperative  network. 

E.  Solutions 

To  help  alleviate  the  problems  enumerated  above,  the  following  actions  were 

initiated: 


1.  There  are  two  tunnel  endpoints  at  ARL,  one  connecting  to  Ft.  Belvoir  and 
the  other  connecting  to  all  the  other  participants.  On  review  of  the  tunnel  endpoint  systems,  it 
was  determined  that  they  were  overwhelmed  by  the  traffic  produced  from  the  CalEx  Federation. 
The  solution  was  to  upgrade  both  systems  to  systems  with  higher  performance  hardware. 

2.  IP  multicast  tunnel  bandwidth  was  increased  from  10  mbits/sec  to  30 
mbits/sec  for  all  sites. 

3.  For  optimal  distributed  simulation  performance,  the  fedex  and  the  rtiexec 
processes  needed  to  run  on  systems  with  sufficient  processor  strength,  as  well  as  run  at  sites  with 
sufficient  bandwidth.  This  helped  ensure  that  the  fedex  and  rtiexecs  processes  were  not  the 
bottlenecks.  The  ARL  site  was  selected  as  the  primary  site  for  running  the  fedex  and  rtiexec 
processor  with  Ft.  Belvoir  designated  as  a  backup  site. 

4.  The  best  effort  mode  proved  to  be  the  optimal  transport  method  in  the 
distributed  exercise  once  networking  issues  had  been  resolved. 
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5.  Firewalls  needed  to  have  ports  and  sites  identified  to  ensure  that  the 
various  federations  could  communicate  across  sites.  Unfortunately,  the  requirements  that  were 
mandated  by  the  RTI  were  never  clarified,  and  many  sites  had  difficulties  resolving  this  issue. 

6.  Networking  stability  was  not  resolved  sufficiently  during  the  CalEx 
exercise.  However,  for  distributed  simulations  to  work  properly,  it  is  clear  that  network 
hardware  intended  for  technical  work  cannot  be  shared  with  network  hardware  used  for 
administration  purposes  such  as  web  surfing  and  email.  There  must  be  a  clear  physical 
separation  of  hardware  to  ensure  one  side  does  not  create  problems  for  the  other.  The  technical 
networking  must  also  have  an  appropriate  process  in  place  to  ensure  that  changes  are  not  made 
without  awareness  and  approval  of  technical  personnel  requiring  network  stability. 

The  DREN  personnel  were  called  in  to  help  investigate  some  of  these  problems. 
The  DREN  team  was  very  supportive  of  CalEx  and  their  assistance  was  greatly  appreciated. 
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IV.  RECOMMENDATIONS 


The  success  of  a  distributed  WAN  simulation  exercise  is  heavily  dependent  on  the 
Network  that  is  used  to  provide  the  backbone  support.  The  WAN,  MAN,  and  LAN  should  not 
function  as  independent  structures,  but  instead  as  tightly  coupled  components  to  form  one 
efficient  and  reliable  Network. 

Throughout  the  course  of  the  CalEx  exercise,  many  network-oriented  challenges  were 
encountered.  The  most  significant  challenges  were  observed  at  the  MAN  level;  however,  it  must 
be  noted  that  some  of  these  were  in  part  influenced  by  infrastructure  policies  at  the  WAN  level. 
The  following  discussion  serves  to  provide  recommendations 

A.  WAN  Structure 

The  central  point  of  control  of  a  network  should  be  at  the  WAN  level.  At  this 
level  it  is  much  easier  to  monitor  and  maintain  control  of  a  WAN  distributed  simulation  exercise. 
The  WAN  drives  the  technology  and  sets  the  standards  and  policies  for  those  sites  that  desire  to 
join. 


During  CalEx,  the  DREN  was  used  to  provide  the  WAN  support.  One 
recommendation  to  be  made  is  that,  in  the  future,  the  DREN  be  capable  of  offering  an 
unclassified  network  service,  a  separate  interface  that  would  provide  a  transparent  encrypted 
ATM  backbone  that  would  not  touch  the  Internet  or  any  other  similar  commercial  network.  The 
desire  would  be  that  this  network  interface  offering  would  be  used  only  to  serve  the  unclassified 
simulation  community.  Sites  that  would  want  to  use  this  interface  would  agree,  via  a 
Memorandum  of  Agreement  (MO A),  not  to  place  firewalls  or  security  routers  in  its  path,  but 
would  use  it  to  directly  connect  the  simulation  participants.  Every  firewall  and  security  router 
employed  increases  latency  on  the  Network.  The  DREN  would  be  solely  responsible  for 
establishing  the  security  practices  and  procedures  of  the  new  interface.  Note,  the  current  service 
provided,  which  peers  to  the  Internet  and  other  general  purpose  networks,  is  valuable  and  should 
be  continued  as  an  offering.  However,  this  new  interface  would  be  of  great  value  in  the 
simulation  community  and  would  help  to  eliminate  some  of  the  latency  that  is  so  detrimental  in 
the  simulation  environment. 

Another  recommendation  would  be  that  the  DREN  be  staffed  to  support  a 
technical  staff  that  would  be  responsible  for  the  following: 

1 .  Scheduling  resources,  tracking  and  providing  consistent  technical  support 
for  large  distributed  WAN  simulation  exercises. 

2.  Maintaining  network  documentation  and  Points  of  Contact  (POCs)  of 
participating  sites  down  to  the  LAN  level.  During  CalEx  it  was  noted  that  MAN  sites  did  not 
desire  to  share  basic  configuration  information  regarding  their  networks  (i.e.  note,  all  the 
“clouds”  in  the  CalEx  network  diagram).  There  needs  to  be  a  central  point  of  control,  which  is 
aware  of  the  entire  structure  of  the  network.  It  is  impossible  to  debug  problems  without  this 
knowledge.  The  LAN,  MAN,  and  WAN  network  have  to  be  looked  at  as  just  “one”  efficient  and 
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stable  Network.  There  has  to  be  at  least  one  group  in  charge  that  has  access  to  the  configuration 
and  structure  of  the  “whole”  Network. 

3.  Provide  pre-engineering  support  to  provide  equipment  recommendations, 
latency,  and  routing  capacity  planning  for  new  sites.  Also,  provide  performance  information 
prior  to  large-scale  exercises. 

4.  Continue  to  provide  research  and  encourage  newer  more  efficient 
technologies.  For  example,  to  lead  the  effort  away  from  the  use  of  Distance  Vector  Multicast 
Routing  Protocol  (DVMRP)  multicast  tunnels  and  encourage  the  use  of  Protocol  Independent 
Multicast  (PIM)  sparse  mode  for  multicast  support. 

B.  MAN  Challenges 

The  MAN  provided  the  greatest  challenges  during  CalEx.  Communication 
with  this  level  for  the  WAN  and  LAN  network  managers  was  very  difficult.  The  MAN 
administrators  are  responsible  for  the  network  activities  on  an  entire  base.  Their  priorities 
oftentimes  are  in  direct  conflict  with  those  of  a  Project  trying  to  execute  a  WAN  distributed 
simulation.  There  needs  to  be  an  infrastructure  put  in  place  that  will  effectively  support  the 
needs  of  the  simulation  community  as  well  as  that  of  the  general  administrative  community. 

Also,  there  appears  to  be  no  commonality  of  MAN  network  structures  between  the  bases.  This  is 
so  important  to  structuring  an  effective  network.  There  should  be  a  commonality  of  equipment, 
standards,  policies,  and  practices  that  are  operative  and  mandated  at  all  bases. 

C.  LAN  Disposition 

The  technology  used  on  this  level  was  a  minimum  of  fast  Ethernet  on  all  sites. 

The  greatest  challenges  on  this  level  were  that  of  the  applications.  Unfortunately,  the  other 
network  challenges  overshadowed  those  on  this  level.  However,  there  were  challenges  noted 
with  the  RTI  [2,3]  and  the  Gateways.  Whether  these  were  caused  by  overall  network  latency,  or 
problems  within  the  applications  themselves,  specific  causes  could  not  be  determined. 
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V. 


CONCLUSION 


Distributed  simulation  of  long  haul  networks  can  and  does  work  well  if  the  network 
remains  stable.  There  is  sufficient  bandwidth  at  most  Army  RDEC  sites  to  handle  reasonably 
sized  exercises.  However,  as  the  DREN  becomes  more  critical,  perhaps  there  should  be  an 
Army  investment  in  infrastructure  to  ensure  all  Army  research  centers  are  connected  to  the 
DREN. 


Infrastructure  needs  to  be  addressed  properly  by  Army  leadership  to  ensure  that  the 
modeling  and  simulation  community  can  execute  the  Army  vision  of  SMART.  Investment  needs 
to  be  made  in  networking  as  noted  above  as  well  as  HLA  as  the  environment  that  will  support 
interoperability. 
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ACRONYMS 


AMC 

RDEC 

ARL 

STRICOM 

HLA 

DREN 

RTI 

LAN 

MAN 

WAN 

TARDEC 

CECOM 

C41SR 

M&S 

FCS 

DIS 

ATCCS 

FOM 

RTI 

GRIM 

RPR  FOM 

APS 

PST 

XDR 

PDU 

CGF 

OTB 

ITEMS 

RWA 

UAV 

VTT 

ES 

OCU 

CERDEC 

NGPM 

CID 

PTN 

NVESD 

EO/IR 

UGS 

GEC 


Army  Materiel  Command 

Research,  Development,  and  Engineering  Center 

Army  Research  Laboratory 

Simulation,  Training,  and  Instrumentation  Command 

High  Level  Architecture 

Defense  Research  &  Engineering  Network 

Run-Time  Infrastructure 

Local  Area  Network 

Metropolitan  Area  Network 

Wide  Area  Network 

Tank,  Automotive,  Research,  Development  &  Engineering  Center 
Communications  &  Electronics  Command 
Command,  Control,  Communication,  Computers  &  Intelligence, 
Surveillance,  Reconnaissance 
Models  &  Simulation 
Future  Combat  Systems 
Distributed  Interactive  Simulation 
Army  Tactical  Command  &  Control  System 
Federation  Object  Model 
Run-Time  Infrastructure 

Guidance,  Rationale,  and  Interoperability  Modalities 
Real-Time  Platform  Reference  FOM 
Active-Protection  System 
Paint-the -Night  and  SWISS  Together! 

External  Data  Representation 
Protocol  Data  Unit 
Computer  Generated  Force 
OneSAF  Test  Bed 

Interactive  Tactical  Environment  Management  System 

Rotary  Wing  Aircraft 

Unmanned  Aerial  Vehicle 

Vetronics  Technology  Testbed 

Embedded  Simulation 

Operator  Control  Unit 

Communication  -  Electronics  Research,  Development,  and 
Engineering  Center 
Next  Generation  Performance  Model 
Commander's  Interactive  Display 
Paint  the  Night 

Night  Vision  &  Electronic  Sensors  Directorate 
Electro-Optical/Inffared 
Unmanned  Ground  System 
Generic  Entity  Controller 

ACRONYMS  (Cont.) 
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CMS 

CTD 

F2DSS 

VDMS 

HPC 

IDEEAS 

ATM 

QOS 

DVMRP 

PIM 


Comprehensive  Mine  Simulation 
Compact  Terrain  Database 
Future  Fires  Decision  Support  System 
Vehicle  Dynamics  &  Mobility  Server 
High  Performance  Computing 

Interactive  Distributed  Engineering  Evaluation  &  Analysis 
Simulation 

Asynchronous  Transfer  Modulation 
Quality  of  Service 

Distance  Vector  Multicast  Routing  Protocol 
Protocol  Independent  Multicast 
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